It is known that testing of the correctness of programs for data processing systems is a basic problem in the electronic data processing field. This problem has not been entirely solved, in spite of the several analysis and test tools which have been adopted.
A basic reason for the difficulty in testing the correctness of a program is that the program behavior largely depends on the data on which the program operates and, in case of interactive programs, on the information (data and commands) received from a user. Therefore even if exhaustive testing is impossible, as is often the case, program testing and verification is preferably conducted by causing the program to operate with some data. In other words, by creating and performing what is defined as a "process " by software designers.
A "process" is commonly defined as an address space, a control thread operating within the address space, and the set of system resources needed for operating with such thread. A is therefore a logic entity consisting of the program itself, the data on which it must operate and the memory resources and input output resources required for running the process. Program verification and the detection of errors (bugs) is therefore the execution of the program as a process thread to test if the process develops in the correct way or if undesired or unexpected events occur. To test a process in the course of its running, the proper art offers two basic tools: tracing functions, or tracers and symbolic analysis functions, or symbolic debuggers. The tracing functions modify a program to be tested so that each program instruction is preceded and followed by instructions which control the printing of the instructions and possible variables used by the instructions before and after execution of the instructions.
The symbolic analysis functions are basically interactive programs which, starting from a source program to be tested, which is in a high level language such as the C language and which is treated as a data file, generate a compiled program as an executable copy of the source. The symbolic analysis functions modify the executable copy of the source so that for each source code instruction it performs a routine which, by means of conditional branches to other routines, allows the user to see on a screen the various instruction sequences and to selectively set break points after each instruction of the object program, using a display of the source as a reference.
The symbolic debuggers further allow the insertion in the object program of routines for recording the variables used in execution of the instruction and, on user request, lists of break point lists and used variables, displaying them on a screen and enabling the user to add and remove break points, to modify variables, and to test the program functions in different environments. These tools are particularly effective in that they permit step by step control of the execution of a program, that is, they allow the evolution of the related process to be controlled by halting and restarting the process at will and by changing parameters during the course of execution of the process. The tools also display the execution of the process to the user in detail by means of display windows which allow the user to continuously monitor the process status and which allow the user to control execution of the process through user intelligible indications.
No matter how effective the tools, such tools suffer from severe limitations. First of all they can test and operate on only a single process at a time, and the monitored process is treated as a "child" process of the symbolic analysis function or process. That means that, in the case of more interactive processes, the monitoring can be performed only on single non-active process phases, which have to be obtained by severing the program into segments. Otherwise, it would be necessary to link the various programs so as to generate a single process whose evolution would then be extremely difficult to follow, even at symbolic level.
Further, the process to be tested must be activated by the father process (the symbolic analysis process) and cannot be activated earlier. The debugging of programs which are activated at system start up, such as monitors, daemons, etc., is therefore impossible.
Eventually, since the process to be tested is generated as a child of the symbolic analysis and in a certain sense is the result of a combination of the symbolic analysis function/program with the program to be tested, the two processes must share or utilize the same resources. As a consequence, interactive program which make use of masks and windows and therefore need a terminal cannot be tested because they compete or interfere with the symbolic analyser in requiring access to the display and control terminal.
These limitations are overcome by the method for program debugging and correctness testing which is the object of the present invention.